This publication uses the term managing to mean all the ways you can monitor and control what is going on with an active Network Utility. These ways include:
This chapter gives an overview of these methods and introduces some of the other products you can use to manage your Network Utility.
To enter commands to query and change box status, you must first bring up a local or remote console attachment to an active Network Utility. For details on how to do this and reach the * prompt, see Chapter 2, Bringing Up a User Console.
Once you have an active console, use talk 5 to access the Console process. 11 From there, you navigate menus and issue commands to query the status of interfaces and protocols, and to make dynamic operator changes such as:
See Operating (Using talk 5, the Console Process) for an overview of talk 5 commands and the types of status you can view and change from the operator console. Full details on the top-level talk 5 commands are provided in the MAS Software User's Guide chapter "The Operating/Monitoring Process (GWCON - Talk 5) and Commands".
By using the talk 5 commands net, protocol, and feature, you can move down in the menu structure and use commands for monitoring and controlling interfaces and particular protocols and features. Interface-level talk 5 commands are documented in the chapters of the MAS Software User's Guide devoted to the different interface types. Protocol and feature talk 5 commands are described in various chapters of the two-volume MAS Protocol Configuration and Monitoring Reference, and in MAS Using and Configuring Features.
Talk 5 commands provide a snapshot of Network Utility status, but cannot produce a log or trace of events happening inside the box. For this you use ELS, the Event Logging System. By activating the right ELS messages and monitoring the event log, you can follow in real time such events as:
By monitoring ELS messages, you can start to answer some basic questions, like:
The Event Logging System is a powerful tool for debugging basic configuration problems.
To use ELS messages, you first tell the system which of its thousands of predefined events you want it to report to you. You can specify the set of active messages using the following criteria:
In addition, you can set up filters on a logical interface number, so that for any active set of messages, only those relating to a particular interface appear in the log.
When you activate messages, you choose one of the following destinations for the message:
You view messages sent to this process using the talk 2 command from the * prompt. See Event Logging (Using talk 2, the Monitor Process) for an introduction to using the Monitor process.
You can set up any PC or workstation that supports a standard syslog facility to receive a flow of event message packets and save them in a file. The Network Utility sends each message in a UDP/IP packet out through a standard network interface. Because log message flow can be heavy, a log server is normally LAN-attached to the Network Utility.
The Network Utility packages the event message in an IBM enterprise-specific SNMP trap, and sends it in a UDP/IP packet out through a standard network interface.
From the command line, you can use either talk 6 or talk 5 to select the events you want to log and where to log them. From either process, enter the event subprocess to proceed. If you activate events under talk 6, the changes do not take effect until you write them to disk and reboot the Network Utility. The messages for those events will be continuously active from the first reboot on.
If you activate events from talk 5, the system immediately begins to deliver messages for those events to the destination you specify (talk 2, the log server, or SNMP management station). When you reboot the Network Utility, those messages cease to be active. Using talk 5 to activate events is a good way to debug an immediate problem you may be having. You turn on the events, quickly jump to talk 2 to see what is happening, and so on. When you reboot later, the events are deactivated without you having to enter any new commands.
Another useful debug technique is to use the talk 5 event subprocess to view statistics of how many times any event has been encountered. These statistics are available even for events that have not been activated.
There is no talk 5 command to activate the current talk 6 ELS configuration. If you want immediate activation, you must repeat the same commands in talk 5 that you entered in talk 6.
From the Configuration Program, you can only set up the Network Utility to do remote logging to a host. You cannot configure which ELS events are active or direct ELS events to a particular destination. The Configuration Program does preserve this configuration information, however, if you retrieve a configuration from a Network Utility, modify other parts of the configuration using the Configuration Program, and write the configuration back out.
From an SNMP management station, you can use SETs to control most ELS configuration functions using an enterprise-specific ELS MIB.
For an introduction to some of the key commands to activate and control ELS events, see Monitoring Events. For a detailed explanation of ELS concepts and the associated talk 6 and talk 5 commands, see the MAS Software User's Guide chapter "Configuring and Monitoring the Event Logging System (ELS)." For a description of every individual ELS message, see the Event Logging System Messages Guide either on CD-ROM or on the Web.
SNMP is an industry-standard protocol that management stations use to query and set configuration, control, and status information in a managed node. In the Network Utility context, the management station would normally be a PC or workstation with an SNMP management software product installed on it. The managed node would be the Network Utility.
SNMP requests and replies flow inside UDP packets through an IP network between the management station and the managed node. In general, the management station initiates communication by sending requests for information and requests to set data items to new values. The managed node simply carries out these requests and replies to them. A managed node can, however, send an unsolicited message called a trap to report an event. A Network Utility might send a trap to report such events as a box reboot or an interface going down.
A Management Information Base (MIB) is a virtual information store defining the data items in the managed node that can be accessed from the management station. MIBs are defined in strictly formatted description files which can be read both by people and by management station software.
A managed node product supports a MIB when its software can field SNMP requests for the data items documented in the MIB, and retrieve or set its corresponding internal data items. The MIB description file defines for each data item whether the management station can only read it, or can modify its value. Sometimes, a product chooses only to allow read-access to a data item that the MIB documents as write-able. You should consult product documentation to understand the level of access a particular product has implemented.
Most industry-standard protocols and interface types have an associated IETF standard MIB with an RFC number. Standard MIBs define data items that are common to most implementations of the associated protocol or interface type. Vendors cannot always wait for a MIB to reach standard RFC status within the IETF, and sometimes ship support for a pre-standard Internet Draft version of the MIB.
In addition to the standard MIBs, many product vendors develop their own MIBs to define data items that are unique to their products. For example, Network Utility supports MIBs that give access to memory and CPU utilization information, for which there is no standard MIB. In SNMP parlance, these vendor MIBs are called enterprise-specific MIBs.
IBM Network Utility supports a comprehensive set of standard and enterprise-specific MIBs for monitoring and managing resources. The current list numbers somewhere between 40 and 50 MIBs.
You can find a "README" file documenting Network Utility MIB support by accessing the appropriate software release directory on the World Wide Web at:
ftp://ftp.networking.raleigh.ibm.com/pub/netmgmt/netu
In the same directory, you can find the MIB description files themselves, ready to be retrieved using FTP and loaded into a management station. Whenever possible the files are compiled into SNMP Version 1 format, to make them compatible with the widest possible variety of management station software.
For the standard and Internet Draft MIBs, the compilation process strips out introductory explanatory text and page formatting that helps make a MIB more readable. To get the full pre-compiled version of an RFC or Internet Draft MIB, retrieve it from an IETF FTP site as you would any RFC or Internet Draft. You can start at the following URL and follows links to the RFC or Internet Draft repository:
http://www.ietf.org
The following MIBs are new for this release:
The Layer 2 Tunneling MIB is an IBM Enterprise MIB which allows you to view information about active layer 2 tunnels and the statistics associated with them. There are traps for tunnel starts and stops and authentication failures. You can also issue sets to a test MIB which will test whether the tunnel can be established, based on the configuration information for that tunnel. There is a test MIB which allows you to determine the response time for a tunnel.
The Policy MIB is an IBM Enterprise MIB which consists mostly of the policy information loaded into the policy database of the router. You can determine where the policies were loaded from, either local configuration, from an LDAP server, or both. The MIB keeps track of the number of times a policy has been hit and any active negotiations that are taking place for IPSec and IKE. The negotiation information can be used to index back into the IPSec/IKE MIB for specific information about the negotiations. You may also look at both the administrative and operational LDAP configuration parameters. The MIB allows you to perform sets, thus changing the configuration, for some of the LDAP parameters. It has an object which causes the policy database to refresh when set. There is also a policy test MIB which allows you to set the selectors for a policy query (Source and Destination IP Address, protocol and port number and DS byte) and determine which policies and actions would result from a policy query with those selectors.
The IPSec/IKE MIB is an IBM Enterprise MIB which allows you to view the active negotiation information for phase I and phase II of IKE. It also provides tables for the IPSec statistics for encryption and decryption as well as errors. There are traps for tunnel starts and stops and authentication and decryption failures. The MIB also displays information about which subnets and applications are being protected and the local and remote identification information for the security gateways.
Before an SNMP management station can communicate with your Network Utility, you must first configure SNMP in the Network Utility with the appropriate access enabled. You can use either the Configuration Program, talk 6, or talk 5 to enable SNMP and set up a community name that grants access to one or more management stations. From talk 6 or talk 5, use protocol snmp to access the Config and Console subprocesses for working with SNMP. As shown in step 3, you can also use Quick Config to enable SNMP and set up a read or a read-write community name.
See the MAS Protocol Configuration and Monitoring Reference Volume 1 chapters "Using SNMP" and "Configuring and Monitoring SNMP" for more background information, and for a description of the SNMP talk 6 and talk 5 commands.
Before a management station can provide any significant support of a managed node, it must know what MIBs that managed node supports. If you are using any of the IBM products described in IBM Nways Manager Products, you do not have to do anything to set this up. Each of them has the MIBs that Network Utility supports already compiled in.
If you are using some other management product, you may have to set up this knowledge. Management stations typically provide a facility for loading compiled MIB modules into the station. When you are preparing a management station to manage Network Utility, set it to read in all the MIBs from the appropriate directory under the URL given in MIB Support.
If you intend to send traps from Network Utility to the management station, you may also need to set up the management station to issue messages or take specific actions on receipt of a trap.
IBM's Systems Network Architecture (SNA) defines a rich set of protocol flows for the purpose of managing network products. A key part of that architecture is the ability for the managed node to send an unsolicited error or event report, called an alert, to an SNA management station. An alert contains a sequence of submessages that enable the management product to report to an operator such things as:
The SNA management product most commonly used to receive alerts is NetView/390. In SNA architecture, such a product is called an alert focal point. A product in the network that can receive and forward alerts on behalf of other products is called an entry point.
When you are using Network Utility as an APPN network node, it has the capability to establish LU6.2 sessions with alert focal points and send native SNA alerts to report error conditions in the box and in the network. The following are some of roughly 30 predefined events that trigger an alert from Network Utility's APPN function:
If one of these events occurs and Network Utility has no current focal point session on which to send the alert, it queues the alert for later transmission. You can configure the depth of this "held alert" queue. You cannot configure which of these events will trigger an alert.
The LU6.2 session on which alerts flow can be established either by the focal point or by the Network Utility. You do not have to configure any special parameters at your APPN Network Utility to enable it to accept a session from an alert focal point and send alerts. If you want the Network Utility to actively set up sessions and forward alerts, you configure the name of one or more implicit focal points as part of your APPN configuration. If the primary focal point cannot be reached, Network Utility attempts to reach the other configured names.
In addition to sending alerts for events it detected, Network Utility can serve as an SNA entry point and forward alerts on behalf of other SNA nodes with which it has sessions. No configuration is required to enable this function.
You can use the Configuration Program or talk 6 to configure focal point names if you want the Network Utility to activate the focal point sessions. From talk 6, use protocol appn to access the Config subprocess for working with APPN, and then use the add focal-point command.
For more background, refer to the MAS Protocol Configuration and Monitoring Reference Volume 2 APPN sections "Entry Point Capabilities for APPN-related Alerts," "Configurable Held Alert Queue," and "Implicit Focal Point." The command names are given in the "Router Configuration Process" section in the same chapter.
Both SNMP and SNA management flows require a product separate from Network Utility, to manage a display of the network and the Network Utility, to query the Network Utility for status, or to receive unsolicited event reports from the Network Utility. This section lists some of the products you might use to perform these tasks.
A MIB browser is a small PC or workstation application that can load MIB definitions, query or set data items in a managed node, and decode returned values and results into a easily readable form. In SNMP terms it is a management station, but a MIB browser lacks the power and sophistication of a full-fledged SNMP management platform such as those described in the following section. MIB browsers are frequently packaged as part of such platforms, but can also be stand-alone products.
The following IBM SNMP network management products are specifically intended to manage Network Utility and a wide variety of other IBM and non-IBM networking products. Each of them provides a graphical topology view of your network resources, with a color-coded status of resources and overall status of each network. Each supports automatic discovery of network resources, and automatic updates to a network map in response to network changes.
Designed for managing medium to large network environments, this product runs on a workstation running AIX, IBM's version of UNIX. Nways Manager for AIX runs on top of Tivoli TME 10 NetView, which was formerly known as "NetView for AIX" and "NetView/6000." Tivoli TME 10 NetView provides general network management platform capabilities such as the management of LAN topologies, fault and event recording, and error logging. When combined with IBM's SNA Server for AIX, Tivoli TME 10 NetView can also map SNMP traps to SNA alerts. For Network Utility, this permits an SNA alert to flow for virtually any defined ELS event.
Nways Manager for AIX provides the following capabilities on top of the base Tivoli TME 10 NetView functions:
When you select a Network Utility from the network topology view, you see a graphic of the front panel of the Network Utility, with color-coded interface status. A navigation window on the side allows you to access all SNMP MIB information provided by Network Utility, either in graphical or tabular form. This application enables you to:
From the Network Utility application, you can launch:
Because the Network Utility management application is Java-based, you need not be at the workstation running Nways Manager to use it. You can bring up the application from a PC or workstation running a JDK-compliant Web browser, connected over your intranet or the Internet to the main Nways Manager workstation. For details on which Web browsers and versions of JDK are required, see the Nways Manager product prerequisites at:
http://www.networking.ibm.com/netmgt
Java management support includes viewing real-time status of the Network Utility and the ability to do performance management. For security reasons, you cannot launch the Configuration Program from a Java web browser.
To provide support for larger networks, you can use boxes other than the Nways Manager workstation to poll the managed nodes in your network. Offloading polling from the manager workstation frees its processor to do other tasks, and it frees network bandwidth because you place the polling closer to the devices being polled. These "agents" of the manager can be configured to notify Nways Manager when thresholds are exceeded.
The intelligent agent software is Java-based and is downloaded from Nways Manager. The agents can be placed in any Java-enabled (Java virtual machine) workstations in the network. Nways Manager can also use the distributed polling capabilities provided by the TME 10 Mid-Level Manager.
Nways Manager for AIX provides an APPN-level view of the topology of your network. You can discover participating APPN resources, view them, and view their status as color-coded icons. APPN protocol performance and error events (data and graph) are also provided. This application does not present Branch Extender or Extended Border Node topologies.
Nways Manager for AIX can also show you a DLSw topology view of your network, including DLSw connectivity, resources, and color-coded status. The topology is refreshed as new nodes are discovered. This application does not present the topology of DLSw IP multicast groups.
Nways Manager for AIX has comprehensive support for products implementing virtual LANs, for ATM networks, and for collecting, correlating, and displaying data from RMON and ECAM probes.
The Nways Virtual Private Network (VPN) Management Application provides a rich set of Monitoring, Event Reporting, Troubleshooting, Operational Control and Application Launching functions. The initial version is specifically targeted to provide monitoring and operational control of the VPN capabilities for the IBM 22xx Router and uses private MIB Objects in providing it's functions as standard MIB Objects do not currently exist.
The Nways VPN Management Application concentrates on three VPN Components:
The Monitoring function allows you to view active and previous VPN Tunnels, view active and previous VPN Clients and view defined and active VPN Policies. The Event Reporting function informs you when a VPN Tunnel starts and when VPN Device experiences a Security Attack. The Operational Control function allows you to disable/inactivate a VPN Tunnel, disable/inactivate a VPN Client and refresh VPN Policies. The Troubleshooting function allows you to Proxy-Ping a VPN device and view VPN Event Failure Logs. The Application Launching function will provide the ability to launch a variety of related network management applications such as the device's PSM/JMA.
The first version of Nways Manager for AIX with specific support for Network Utility is Version 1.2.2.
For more information about Nways Manager for AIX including specifications and system requirements, go to:
http://www.networking.ibm.com/cma/cmaprod.html
The pages at this site describe the separately priced components of Nways Manager for AIX, and which components perform which of the above functions.
Designed for managing small-to-medium network environments, Workgroup Manager is a 32-bit native Windows NT application that operates on NT Version 4.0. Unlike Nways Manager for AIX, Workgroup manager is self-contained and does not use an underlying network management platform. It must therefore provide a number of platform functions itself.
Key features of Nways Workgroup Manager for Windows NT include:
Nways Workgroup Manager for Windows NT supports exactly the same Network Utility-specific Java management application as Nways Manager for AIX. You can run the Network Utility management application from a Java-capable web browser. Nways Workgroup Manager for Windows NT also supports Distributed Intelligent Agents.
Nways Workgroup Manager for Windows NT does not support the APPN and DLSw topology applications that Nways Manager for AIX does. The Nways Workgroup Manager for Windows NT topology display is based on IP connectivity between the managed nodes.
The first version of Nways Workgroup Manager for Windows NT with specific support for Network Utility is Version 1.1.2.
Designed for managing medium-to-large network environments, this product runs on a workstation running HP-UX, Hewlett Packard's version of UNIX. Nways Manager for HP-UX runs on top of HP's Network Node Manager management platform software, previously known as "HP OpenView."
In this environment, network node manager provides the base management platform functions, including topology display, trap management, and so on. Unlike Nways Manager for AIX, it enables you to associate IBM network devices with the appropriate Nways Manager for HP-UX management application.
From Nways Manager for HP-UX, you can launch the same Network Utility-specific Java management applications as you can from Nways Manager for AIX. Nways Manager for HP-UX also supports Distributed Intelligent Agents.
Nways Manager for HP-UX does not support the APPN and DLSw topology applications that Nways Manager for AIX does.
The first version of Nways Manager for HP-UX with specific support for Network Utility is Version 1.2.
NetView/390 is a host-based management product for managing medium-to-large SNA networks. There are several ways you can use NetView/390 to manage a Network Utility and the SNA products it can connect to the host: